home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc Development Framework / ODF-Interest Archive / August 96 / Re Focus Sets < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.5 KB  |  [TEXT/ttxt]
  1. Subject:     Re: Focus Sets
  2. Sent:        8/2/96 11:47 PM
  3. Received:    8/5/96 8:42 AM
  4. From:        lamiraux@ix.netcom.com
  5. Reply-To:    ODF Interest, ODF-Interest@CILabs.ORG
  6. To:          OpenDoc Development Framework Discussion List, ODF-Interest@CILabs.
  7.  
  8. One problem I can see is that the embedded frame is going to always 
  9. grab its focii on mouse up unless you flag it as selected (using the 
  10. FW_MProxy API). If the user pressed option, in your 
  11. DoMouseDownInEmbeddedFrame you need to change the select state of the 
  12. embedded frame so it will grab its focii on mouse up. Don't forget that 
  13. activation happens on mouse-up not on mouse-down and there is no way 
  14. for a container to avoid that one of its embedded frame get activatated 
  15. unless the embedded frame is selected or bundled.
  16.  
  17.  
  18. -----------------------------------------------------------------
  19.  
  20.  
  21.  
  22. >I hate to ask these "how do I" questions, but I have been battling this one
  23. >for two days and am totally confused at this point.
  24. >
  25. >This is for Rapid-I Button. Here's what its focus behavior needs to be.
  26. >Like ODF Embed, the button can have (but doesn't always have) 1 embedded
  27. >part (which is a label). Like ODF Button, when the user clicks on the
  28. >Rapid-I Button or its embedded part, the button should track - neither the
  29. >Rapid-I Button nor the embedded part should grab focii. If the user
  30. >option-clicks on the embedded part, it should grab its desired focii. If
  31. >the user option-clicks on the portion of the Rapid-I Button which is not
  32. >the used shape of the embedded part, Rapid-I Button should grab its focii.
  33. >
  34. >The "RIButtonFrame" class is the only view class that Rapid-I Button uses.
  35. >I don't actually use control views or the Mac's Control Manager.
  36. >
  37. >I tried using the "COptionBehavior" and "CButtonFrame" ways of dealing with
  38. >focii from ODF Button. I also tried adding a "DoMouseDownInEmbeddedFrame"
  39. >method to both the COptionBehavior and RIButtonFrame classes.Walking
  40. >through the debugger, I can't find a consistent ordering to the execution
  41. >path going through COptionBehavior::DoMouseDown,
  42. >RIButtonFrame::GetFocusSet, and RIButtonFrame::DoMouseDown.
  43. >RIButtonFrame::GetFocusSet can be called before or after
  44. >COptionBehavior::DoMouseDown. I can't make any sense of it.
  45. >
  46. >So, how _should_ I go about getting this focus set stuff to work right?
  47. >
  48. >Brad
  49. >
  50. ><mailto: "Brad Hutchings" brad@hutchings-software.com>
  51. ><http://www.hutchings-software.com>
  52. >
  53. >Got OpenDoc? Got Cyberdog? Then beta-test Rapid-I Button! Email me for more
  54. >information...
  55.